The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
The computers of an enterprise may consume remote resources, such as web services. A remote resource may reside on the premises of the enterprise, be hosted by a partner, or offered to the public by a third party. The integrity and authenticity of a remote resource may be ensured by a public key digital certificate that is offered by a remote computer, such as a web server, that serves the remote resource. A remote server may use a digital certificate to provide transport security or message security. Digital signing achieves message security by affixing a certificate directly to a payload object being sent from a remote server to a client. Transport security is achieved when establishing a connection between a client and a remote server is accompanied by a certificate, such that all objects exchanged over the connection derive security from the behavior of the connection. Regardless of whether a certificate is used to provide message or transport security, the remote server presents the certificate to the client for inspection. A malicious, impersonating, or compromised remote server may present a bad certificate that is fake, tampered, or otherwise deceptive. A bad certificate can enable theft, sabotage, or fraud, such as a man in the middle (MitM) attack.
Authenticity may be enhanced if a certificate is signed by a trustworthy third party such as a certificate authority (CA). However, agreement between client and server may be lacking as to which certificate authorities are trustworthy. To work around this problem, some systems use certificates that are not authenticated by a CA, such as self-signed certificates. These systems require a user to manually approve each certificate the first time that it is received, such as through a click-to-accept mechanism that provides a user with some information about a certificate and then remembers whether the user accepted the certificate as trustworthy. Remembrance of a certificate by a client is known as certificate pinning. Pinning burdens an end user with assessing the trustworthiness of a certificate, which may be unreliable.
Certificates may be scrutinized by a public system, such as a certificate reputation system, which can achieve better authentication than pinning. A certificate reputation system is intrusive because a client application must be adapted to use the certificate reputation system. Because a certificate reputation system is typically operated by another institution and expects to harvest connectivity data, a certificate reputation system is inappropriate for a sensitive private network. The unsuitability of a certificate reputation system may also be technical, due to obstacles such as a firewall. Because a certificate reputation system relies on crowd sourced data, another limitation of a certificate reputation system is that an attacker may pollute the reputation database with false information.